A telecommunications network is composed of a wide array of devices that employ a litany of technologies. A common task involves processing data transactions. Although a transaction may take many forms, typically a transaction updates a database. Databases are ubiquitous throughout a network and may exist in many devices: switches, routers, signal transferors, etc. In some instances, a database is nothing more than a collection of records. But often, a database is quite complex and executing a transaction is commensurately complex. A transaction may be necessary to update routing. Destination addresses may need to be changed. Switch designations may need to be modified. The types and ramifications of the different types of database modifications (transactions) are nearly limitless.
Executing a transaction may require several substeps or processes to be performed. To analogize, mailing a letter to a destination requires several substeps: collection from a sending location, delivery to sorting facility, emergence from a series of sorting events, distribution to a delivery facility, etc. Continuing this parallel, the prior art does not provide for a way to automatically inform a user that these subprocesses have been completed.
In the telecommunications environment, a transaction may need to be received, transmitted, scheduled, validated, etc., before finally completing. A problem that plagues communications carriers is related to monitoring the progression of transactions. Historically, a manual, one-transaction-at-a-time query method is used to monitor transaction processing. Such a method is slow and prone to error. To successfully query, a user had to know what information to key in, what information to monitor, what interfaces to navigate and type in search criteria, and how to interpret the data that was returned.
This prior art method was accomplished by successive query requests manually submitted. One of the easiest ways this was accomplished was for a user to repetitively press an update button, whereby a single transaction's status would be provided. Successive button presses would produce successive updates. But even this method required manual intervention, prevented a user from accomplishing other tasks until the transaction executed, and retrieved updates regarding only a single transaction.
The prior art relied upon a “pull” type of technology, where a user would manually “pull” or request status updates. Because users would typically be locked out of their workstation as the transaction completed, they would repeatedly submit status-update requests to determine whether the transaction was processing as anticipated and to know when they would be able to move on to other tasks. These many requests would consume valuable bandwidth and slow related systems.
This method of manually requesting updates required a user to have in-depth knowledge of a desired transaction's attributes in order to submit an update request. Moreover, the user who submits a request is typically the only user who can monitor a request. The querying process itself slows the notification that the user needs regarding the status of the desired transaction. Transactions are limited to being monitored one at a time in any prior-art schemes.
The present state of the art could be improved by providing a transaction-processing system that dynamically provides transaction-processing status updates automatically in real time. The art could be further improved by providing a method to asynchronously facilitate the execution of transactions in a networking environment. Finally, there is a need to be able to provide transaction status updates to multiple, rather than a single, receiving component.